Release: merge development into beta - #4580

🔴 Blocker — A form payload's id picks the uuid, and a scoped draft save then writes over any draft with RBAC off

pairsOf() drops only _ and @ keys when a write has no mapping, so a submitter's id reaches $plan['object']. writeAll() passes uuid: null for a fresh submit or a new draft, and SaveObject::extractUuidAndSelfData() (SaveObject.php:3538-3539) then takes $data['id'] as the uuid. SaveObject looks that uuid up with _rbac: false and, when it exists, takes the update branch (handleObjectUpdate, SaveObject.php:3330).

For a scope-value owner (decision 195), writeAll() saves with _rbac: false. refuseSomebodyElsesDraft() returns early when RBAC is off, and DraftStatusPolicy::resolveStatus() accepts draft → draft. So a portal resident whose form has no mapping can send { "id": "<another person's draft uuid>", ... } to saveDraft() and overwrite that draft in the destination schema. The victim can be another resident or a Nextcloud user. The draft keeps its owner, so the victim later finds and submits content they did not type. The comment at lines 685-697 ("Updating or sending it was authorised by DraftFinder::own() before this write") does not hold on this path: own() is only asked when $draftId is set.

The same key affects a fresh submit under RBAC. A uuid the caller cannot read goes down checkSavePermissions()'s create branch (ObjectService.php:2275-2287). It is judged by the schema's create rule (for an anonymous visitor on a public form: the public create rule) and then stored over the hidden object. refuseSomebodyElsesDraft() closes that only for drafts.

I could not check whether the in-process callers (the portal) ever pass mapping: null. The spec explicitly allows it ("without a mapping the payload minus _ and @ keys is the object"), and FormsController::payload() forwards id too. Uncertain, so a blocker under Strict.

Impact: a form submitter (anonymous on a public form, or a portal resident through a scoped draft) can change existing objects of the destination schema that they cannot read, including other people's drafts.

Suggested fix: in pairsOf(), also drop id and uuid when no mapping is given, so a submit never chooses its uuid. The only way to name an existing object is then $draftId, which goes through DraftFinder::own(). As a backstop, in writeAll() refuse when $uuid === null and the object still carries an id.

Done when:

• a new FormSubmitServiceTest case: saveDraft() with a scoped owner, mapping: null and payload id = another owner's draft uuid either creates a new object with a fresh uuid or is refused, and the other draft's data is unchanged. The test goes red with the id filter removed
• the same for submit() with an anonymous subject and the id of an existing object

Reachability: a scope-value owner is only created through DraftOwner::portalSubject() / scoped() by an in-process caller; no caller in this repository creates one, so the write path is reached through the portal app's use of saveDraft(). Reported as a blocker under Strict because the payload id is not stripped on a write that runs with RBAC off.

Tracked as #4664: filed rather than fixed here because the fix lands through development and this release PR is re-cut after every merge.

🔴 Blocker — Bulk delete ignores every draft rule

The draft delete rules live only in deleteObject(): the lookup under the read RBAC (which hides somebody else's draft), isDeletableDraft() for archival schemas, and permanent = true here. deleteObjects(), behind POST /api/bulk/{register}/{schema}/delete (BulkController::delete, @NoAdminRequired), has none of them.

So any user with delete rights in a schema can remove another user's draft by uuid, and the removed draft's content stays in the trash.

Sibling of the open thread at DraftStatusPolicy.php:295 (bulk save over somebody else's draft). That thread covers the bulk save path, not the bulk delete path. The root cause is the same: PermissionHandler::hasPermission() has no draft rule. Putting keptFrom() into hasPermission() when an object is passed would close both threads and f3.

Suggested fix: in deleteObjects(), for each pre-resolved row that isDraft(): skip it (reason OBJECT_NOT_PERMITTED, the same answer as an unreadable row) when $_rbac is on and DraftStatusPolicy::keptFrom() is true; otherwise pass permanent: true and skip the archival gate, as deleteObject() does.

Done when:

• a deleteObjects() test: user B bulk-deleting user A's draft gets it in skipped_uuids and the draft still exists; A bulk-deleting it removes it permanently and writes one draft.removed entry
• the same test goes red with the new branch removed

Tracked as #4665: filed rather than fixed here because the fix lands through development and this release PR is re-cut after every merge.

🔴 Blocker — /api/audit-trails/readable shows other users' draft contents

A draft's saves write ordinary create/update audit rows, and their changed column holds every property's old and new value (AuditTrailMapper.php:878-884). GET /api/audit-trails/readable (@NoAdminRequired) decides per row through mayRead() → PermissionHandler::hasPermission(action: 'read', objectOwner, object). hasPermission() has no draft rule (the draft rule lives only in the SQL predicate, MagicRbacHandler::reachableRowSqlFor()). Any user with read rights on the schema therefore reads, in this list, what another user typed into a draft that the object API hides from them ("a draft answers to its owner only", decision 180). WITHHELD_FIELDS removes session, request and ipAddress but keeps changed.

Sibling of the open thread at DraftStatusPolicy.php:295, which has the same root cause (hasPermission() has no draft rule) but is about a different path.

Impact: draft content (possibly personal data a resident has not yet decided to send) is readable by colleagues while the draft lives.

Suggested fix: add the draft rule to PermissionHandler::hasPermission() when an object is passed: refuse read (and every other action) when (new DraftStatusPolicy())->keptFrom($object, $schema, $userId) is true. That one change also closes f2 and the bulk-save thread.

Done when:

• a ReadableAuditTrailListerTest case: user B, with read rights on the schema, does not get the audit rows of user A's draft. It goes red without the draft rule
• user A still gets them

Tracked as #4666: filed rather than fixed here because the fix lands through development and this release PR is re-cut after every merge.

🟡 Concern — Two concurrent leave-draft requests both announce the creation

The spec (object-events) says a listener on ObjectCreatedEvent "SHALL receive every object exactly once". promoteDraft() and DraftActivation::activate() (line 142) first check that the object is still a draft (DraftFinder::own() / ownDraft(), a plain read), then save, then call leftDraft() without asking whether the save left draft. Two requests on one draft, such as a double click or a client retry (with no Idempotency-Key or with different keys), can both pass the check before either commits. The second save then loads the now-active row, and DraftStatusPolicy::resolveStatus() returns early at line 114 because active === active, so it raises no refusal. The save goes through as an ordinary update: ObjectEventGate::updated() sends ObjectUpdatedEvent, and leftDraft() sends ObjectCreatedEvent and ObjectActivatedEvent a second time. The result is duplicated webhooks, flows, created notification rules and receipts. Nothing locks the draft, and the save has no version check.

Suggested fix: let the save report whether it used the promotion allowance, for example DraftStatusPolicy::consumePromotion(uuid): bool, or check isset(self::$promotions[$uuid]) after the write. Call leftDraft() only when the allowance was used, and otherwise answer as for a draft that is gone (404/409). Better still, refuse the write in resolveStatus() when an allowance exists for a uuid that is no longer a draft.

Done when:

• a FormSubmitServiceTest and a DraftActivationTest case where saveObject returns an object whose stored status was already active (the allowance was not used): no ObjectCreatedEvent is dispatched. Both go red with the check removed

🟡 Concern — Drafts beyond the 5,000-read cap are neither expired nor counted as deferred

The spec says: "at most 5,000 drafts read per register and schema. What is left SHALL be counted as deferred and SHALL wait for the next run." expiredIn() reads every draft (_drafts=true), with no date filter, in PAGE_SIZE pages up to MAX_PAGES, and filters by age in PHP. When a schema holds more than 5,000 drafts, the expired ones after the 5,000th row are never read. They are not counted as expired or deferred, so the log and occ openregister:drafts:expired report less than is really there. Whether a later run ever reaches them depends on the list's default sort. With a stable order, the same first 5,000 rows are read on every run, so expired drafts further down are never removed.

Suggested fix: filter in the query (@self[updated] before the cutoff, with a fallback to created), so the 5,000 rows read are 5,000 expired drafts. When the last page is full, count what remains as deferred (or report "more than N").

Done when:

• a DraftExpiryTest case with an objects fake that returns 5,000 fresh drafts followed by expired ones: the expired ones are removed, or counted as deferred, and never missing from the counts

🟢 Minor — Validator and service disagree on referenceKey: uuid

ReferentialIntegrityService::extractReferenceKey() treats referenceKey empty or uuid as a plain uuid reference (all onDelete actions apply). The validator refuses any non-null referenceKey unless onDelete is RESTRICT, so referenceKey: uuid with CASCADE is refused at save although the service would honour it. Use the same normalisation in both (e.g. a shared static ReferenceKey::of($property)).

🟡 A blocked portal task is still listed and completable in the portal

#4595 (a-task-may-wait-on-another-task) says an inbox read SHALL leave out every blocked task, in its results and its total. The exclusion lives in applyBlockedExclusion(), which only applyInboxPredicates() calls. An external (portal) task is excluded from every Nextcloud inbox (applyExternalExclusion()), so the portal list is the only inbox it has. That list is PortalTaskService::listForSubject() (extended by #4569) over TaskMapper::findOpenExternalForParty() / countOpenExternalForParty(), and applyPartyPredicates() filters on assignee, performer type and is_terminal only. Composed:

1. A portal task created with blockedBy shows up in the citizen's task list and count the moment it is created, not when its blocker closes. The released re-announcement from TaskBlockerReleaseListener then announces a task the party has been looking at all along.
2. PortalTaskService::complete() → TaskService::complete() never reads blockedBy (the only blocker check in TaskService is refuseHandWrittenState() on create), so the party can complete the task the case meant to hold back.
3. Each row goes through TaskInboxService::row() without openBlockers (PortalTaskService.php:137), so every row runs its own blocker query. design.md D-3 says "No query per row". inbox() batches; the portal list does not.

Neither PR saw the other: #4569 merged on 11 Oct, #4595 on 12 Oct.

🟡 Personal data in a draft cannot be found by a data-subject request

Three PRs combine here. None of them covers this alone:

• feat(objects): a draft is the destination object, in status draft (decision 180) #4566 makes a draft the destination object. It holds the half-filled form input, which is often a name, address, BSN or e-mail.
• feat(objects): a draft holds its creation side effects until it leaves draft (decision 227) #4633 holds every ObjectCreatedEvent/ObjectUpdatedEvent listener from a draft until it leaves draft. ObjectChangeListener is one of them (the spec names it). It queues text extraction and entity recognition, and those write openregister_entities / openregister_entity_relations.
• feat(objects): a draft's owner makes it definitive, and a schema sets a draft lifetime (decision 216) #4600 lets a schema keep drafts forever (draftLifetimeDays: false).

The data-subject machinery finds a person's objects only through that index: DataSubjectRequestService::findSubjectObjects() → discover() → matchEntities() reads openregister_entities joined to openregister_entity_relations. Erasure preview and export use the same path (ErasurePreviewService::preview() line 128). A draft is never in that index, so access and erasure requests miss it. On a schema with draftLifetimeDays: false that lasts indefinitely. Even when the entity index does hit a draft, loadObject() reads it with _rbac: true, and the draft predicate hides it from anyone but its owner and administrators.

Removing a draft does not fully remove its data either. Every save of a draft writes a full create/update audit row with its values (SaveObject lines 4018-4027 and 6352). The removal spec keeps those rows on purpose ("The entries the draft's own saves wrote before the removal are not changed"), but the delete requirement promises "no tombstone of unsent input is kept" (openspec/changes/draft-owner-activation-and-lifetime/specs/form-destination/spec.md:189). Both statements cannot be true.

The draft-creation-side-effects proposal lists text extraction as deliberately held, with no mention of GDPR. I did not check whether a DSAR export has a second, non-index discovery path. Grep found none (findSubjectObjects is the entry point used by erasure).

🟡 Another user's hidden draft blocks a RESTRICT delete

#4570 adds RESTRICT by key: keyReferenceBlockers() → findReferencingByKey() → findReferencingInMagicTable(). The $ref RESTRICT path that already existed reaches the same raw SQL. That SQL filters _deleted IS NULL and nothing else, and the loop here skips only deleted rows. #4566 adds drafts: a draft is visible to its owner only and expires after 30 days. A draft holds whatever a half-filled form cited, such as a code from a code list.

Together: user A's draft that cites code X stops user B from deleting X. B gets a 409 whose blockers[].objectUuid names an object B cannot open, list or resolve. B can only wait until A sends the draft or it expires. A pending draft can also block a planned deletion. The draft spec calls a draft "not yet a record: it holds unsent input", and the delete path then counts it as a live referrer. CASCADE/SET_NULL on uuid references reach into other users' drafts in the same way.

Pick one rule for drafts in referential integrity and apply it to both lookups (uuid and key). Either drafts do not block (they cannot be seen and will expire), or they block without revealing their uuid to a caller who cannot read them.

🟡 CHANGELOG omits this release's upgrade-visible behaviour changes

The release adds three CHANGELOG bullets, all about drafts. These changes ship to beta with no entry:

• fix(rbac): a roles block that resolves to nothing grants nothing #4589: a schema/register roles block that resolves to nothing used to leave the schema open and now grants nothing on read/create/update/delete (PermissionHandler::grantNothingWhenEmpty()). On upgrade this can take access away from users. It needs an upgrade note like the drafts one.
• feat(files): a frozen or archived object's files refuse every write, through the files API and through Files or WebDAV #4549: every file write, create, delete and rename under an archived or frozen object's folder is now refused, also through WebDAV/Files (FrozenNodeWriteListener on four node events). Clients that attach files to archived objects start getting errors.
• fix(settings): personal settings move into the user settings dialog #4587: the personal settings section (<personal>OpenRegisterPersonal) is removed and moved into the in-app user settings dialog. Nextcloud's personal settings no longer show it.
• feat(audit): an object's history is readable by whoever may read the object #4614: an object's audit trail is now readable by anyone who may read the object. That is an exposure change admins should know about.
• New public API surface: POST /api/forms/{formId}/submit|uploads|draft, POST /api/forms/validate (feat(forms): a form submits into its destination object (decision 179) #4563), POST /api/objects/{register}/{schema}/{id}/activate (feat(objects): a draft's owner makes it definitive, and a schema sets a draft lifetime (decision 216) #4600), GET .../{id}/tree (feat(relations): read an object's tree along its declared parent property #4656), /api/record-templates CRUD (train: land 10 openregister PRs (12 Oct) #4595), POST /api/migration-packs/preview (feat(migration-packs): view and edit migration packs in OpenRegister #4602), and the example-set occ commands.

git grep -n -i 'roles block\|frozen\|archived object\|personal settings' CHANGELOG.md returns nothing.